fix(modules): gate the module pin conflict on the cohort, not the flag - #3409

Every client module of every hosted project answered 409 Unknown dependency snapshot in production. No page hydrated.

The defect

src/modules/server/module-server.ts:417 conflicted a module request whenever the pinning flag was set and the request carried no pin key:

(!hasRequestedPinKey && dependencyPinningEnabled)

That is the flag, not the cohort. Production runs VERYFRONT_DEPENDENCY_PINNING=1 with ROLLOUT_PERCENT=0 and no project allowlist, so no project is in the cohort and every document correctly emits no pin key. The document and the module handler therefore disagreed: one emitted no key, the other refused every request that lacked one.

dependency-pinning-cohort.ts states the property this broke:

"An absent or malformed percentage collapses to zero so a typo can never widen the rollout, which is the property that keeps the already-armed production pinning flag inert until it is deliberately ramped."

The armed flag was not inert. At 0% it conflicted 100% of client modules.

Reproduction

Locally, against the real production release, with the environment read off the live deployment rather than guessed:

Production returns the same 409 for /_vf_modules/pages/index.js, so the reproduction is faithful.

Fix

Consult the cohort, which is what decides who is actually pinning. A project genuinely in the cohort that omits its key still conflicts — that path is unchanged and its existing tests still pass.

Proof

Regression test written first, red before the change with the exact production symptom:

serves a client boundary for a project outside the pinning cohort ... FAILED
AssertionError: Values are not equal.
-   409
+   200

Green after. End to end with the rebuilt binary, production env, real release:

/_vf_modules/_veryfront/react/runtime/core.js   409  ->  200 (4964 B)

Zero 409s remain on any module path. Two project-module URLs return 503 in my sandbox from a separate release-asset-manifest branch that also fires with pinning disabled, so it is not this defect and not this fix.

Suite: 268 passed / 3344 steps across modules, security, handlers, and transforms/esm. deno fmt clean.

Not fixed here

The same pages also violate CSP: the document references esm.sh, images.veryfront.com, and fonts.googleapis.com while the default policy is 'self'-only. I confirmed this is independent of this fix — with modules serving correctly, the document still carries 6 esm.sh references and 291 image references.

I did try adding the ESM CDN to the default script-src and reverted it: an existing test, "default CSP admits no remote hosts or broad network schemes", fails with script-src must not hardcode a remote host. That strictness is deliberate, so widening it is a design decision rather than a bug fix, and it belongs in its own change with an owner who can make that call.

Summary by CodeRabbit

• Bug Fixes
  • Corrected dependency-pinning rollout behavior for projects outside the configured rollout cohort.
  • Client-boundary modules now load successfully for out-of-cohort projects, even when dependency pinning is enabled.
• Tests
  • Added regression coverage to verify successful JavaScript responses and proper rollout handling.